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Description 

Distributed system and method for displaying . and editing 
medically relevant data objects 

The invention relates to a distributed system and a method for 
displaying and editing medically relevant data objects. 

The health sector is making increasing use of electronic 
patient records. These contain details relating to the 
patient's identity and can store not only information relating 
to current medication and to current findings but also the 
pathogenesis and the patient history. Electronic patient 
records can show all the information from conventional paper 
records and also have the known advantages of electronic 
records, such as outstanding portability and availability. In 
the medical sector, data objects permitting simultaneous 
storage of image data and metadata have recently been 
increasingly implemented for electronic patient records. 

Examples of such data objects are the DICOM standard and the 
GEHR format (in relation to the latter, see: Validating 
Electronic Health Records Using Archetypes and XML, Tun Z., Bir 
L.J. and Goodchild A., CRC for Enterprise Distributed Systems 
(DSTC Pty Ltd) , 

http: //titanium. dstc .edu.au/papers/acs2 002 .pdf) . The metadata 
which can be stored in such data objects can be text or numbers 
and can contain references to the likewise stored image data, 
which can form the basis of a diagnosis. The diagnosis itself 
can be produced manually or automatically. The metadata, 
"Structured Report (SR) objects" in the DICOM standard, can be 
generated automatically by a Computer Aided Diagnosis (CAD) 
application or can be input manually by a medic in the form of 
a finding. 
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Even more than in many other areas of daily life, the health 
sector has particularly stringent demands on standards relating 
to the security and the format of patient data. These stringent 
demands are also relevant for obtaining and receiving the 
legally required licensing for technical medical equipment. 
They make it difficult for the standards to be frequently 
altered or alternated. The licensing problem, in particular, 
but also the necessary long-term availability of patient data 
require long retention of once recognized data formats and data 
processing systems . 

To provide a format for medical data objects which is able to 
be used for as long a term as possible, there is a quite 
general syntax or a quite general data format available for 
metadata which is intended to be able to handle virtually all 
conceivable medical reports which can be produced on the basis 
of the underlying data object. This does not merely require all 
current conceivable medical reports to be able to be produced, 
but also virtually all conceivable reports in the coming years, 
on account of the longevity of standards in the health sector. 

The image data and metadata are presented in reports using 
"templates" (the archetypes in GEHR standard) , which define a 
particular format for particular questions using particular 
data from the patient record. By way of example, there is such 
a template for mammography examinations, another for cardiac 
catheter examinations etc. Since there are many different 
examinations, whose number will increase further in future, 
there will also be an increasing number of templates. 

Since the metadata following a quite general syntax, humans are 
able to read them only with difficulty. If XML is chosen as the 
syntax, for example, data structures containing a large number 
of structuring and formatting commands in addition to the 
actual information are obtained. The large number of these 
commands means that the unpracticed reader, that is to say a 
medic, for example, can identify the relevant data only with 
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difficulty. Instead, the medic, as a typical user of such data, 
much prefers the metadata to be presented in a form which 
humans can read, possibly together with associated image data. 
He would then like to be able to print this presentation in the 
form of a report, for example, and to forward it to another 
treating physician. The report then contains only the relevant 
values from the metadata, which are compiled and displayed in 
line with a mask, e.g. a Word mask. 

The report mask's appearance can be known to the user, can 
follow a scheme, can be recognizable and can further simplify 
the legibility of the data. Such a report can contain not only 
the metadata but also the reference images, e.g. CT or X-ray 
pictures which clarify the diagnosis. In addition, besides 
information on the patient record, other components such as the 
logo and the address of the physician's clinic can also be 
contained in the report, and formal aspects such as the design 
of the letterhead can be covered. 

Previously known standards for electronic patient records, such 
as the GEHR format, are based on a standard format for image 
data and metadata which needs to be observed by all users. To 
allow for the different requirements of individual users with 
regard to the structure of reports for presenting the image 
data and metadata, there are masks, "archetypes" in the GEHR 
standard, which can be developed and altered by the respective 
user, e.g. by a medic or by a clinic. The masks are knowledge 
objects, so to speak, which are used for report writing using 
the respective relevant data from the patient's record. The 
syntax of the masks then allows the relevant information to be 
read from the patient record and to be shown in suitable 
presentation formats such as value lists or tables. One 
possible example of a syntax which is suitable for this purpose 
and conforms to the patient record is XML. 

Hence, although previous masks ensure good legibility for the 
user, they can be generated and altered only by users who have 
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experience of handling the mask syntax. In addition, they do 
not ensure that there is any way of altering or inputting the 
patient records' data contained in the record. 

The aim of the invention is that, on the basis of a patient 
record with a firmly prescribed, standard data format, it 
should become possible to display the data in a wide variety of 
reports which can easily be generated or altered by a user who 
is generally inexperienced with regard to data syntax and is 
untrained, particularly with regard to the data syntax of the 
patient record, and which additionally allow the data contained 
to be input and altered. 

The invention achieves this aim by means of an apparatus in 
accordance with the first patient claim and by means of a 
method in accordance with the other independent patent claim. 

A fundamental concept of the invention is to store the patient 
record in data formats firmly prescribed by the manufacturer, 
on the one hand, and to display the data in variable 
presentation formats, on the .other, by using mutually isolated, 
distributed data processing systems and methods. This allows 
optimum fulfillment of the different demands on standardized 
data management in the patient record, on the one hand, and on 
the greatest possible degree of user friendliness when the data 
are being handled by a user who is unpracticed in data syntax, 
on the other. 

In one advantageous variant of the invention, for the report 
presentation of the data, a syntax for the report masks is 
chosen with which the inexperienced user is familiar from the 
outset. Suitable report presentations for this are based on 
programs in widespread use, such as Microsoft Word using the 
script language Visual Basic for Applications (VBA) . These are 
familiar to a large number of users and provide even laymen 
with easily manageable ways of producing report formats 
incorporating electronically stored data. In addition, such 
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programs are available virtually everywhere and the patient 
data can therefore be viewed virtually everywhere. 

Another fundamental concept of the invention involves choosing, 
on the basis of an electronic patient record in a standard data 
format, a report syntax which provides the average user not 
only with a simple way of editing the masks but also with the 
opportunity not just to display and to present data belonging 
to patient records but also to input them and to alter them. 
For this, the application on which the report syntax is based 
needs to have a bidirectional interface which it can use both 
to receive data from the electronic patient record and to write 
them or write them back to it. This makes it easier for the 
user to edit the data, since he can recover the data to be 
altered in the report context with which he is familiar and can 
associate them more easily and can use this report context as 
an input form at the same time. 

In another advantageous variant of the invention, the content 
of data in the electronic patient record which have been input 
or altered by a user using reports is initially checked before 
the data are written back to the patient record. In this case, 
the content check can relate to the plausibility of the data 
per se by checking, by way of example, conditions such as 
consistency between the patient's sex and sex-specific 
diagnoses which have been input, but it can additionally also 
check the plausibility of the report data in their relationship 
with the data already present in the patient record. This makes 
it possible to avoid mistakes when inputting or altering 
patient data or when associating patient data with patient 
records . 

Other advantageous variants of the invention are covered by the 
subclaims. 

The invention is described in more detail below using exemplary 
embodiments with reference to the figures, in which: 
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FIGURE 1 . shows a system architecture in accordance with the 

invention, 

FIGURE 2 shows a system architecture in accordance with the 

invention with automatic association of report forms, 

FIGURE 3 shows a .distributed method in accordance with the 

invention . 

Figure 1 shows a system for data processing in accordance with 
the invention. In this arrangement, a central component is a 
first data processing device 1 which has a keyboard 3 and a 
screen 5. The first data processing device 1 is used for 
displaying, editing and storing image data and metadata. It 
obtains the image data from a medical workstation for an 
imaging method, e.g. these can be CT, X-ray or NMR image data. 
The first data processing device 1 receives the image data via 
an image -source interface 7 and stores them in a data store 9. 
The image data can also be viewed and, if appropriate, can be 
subsequently edited graphically, and it is also possible for 
metadata in the form of text or numbers to be added. The 
metadata can serve to identify the patient, and they can also 
comprise other personal details, notes relating to the image 
data or information relating to findings. Image data and 
metadata together form data objects whose format corresponds 
accordingly to a suitable, uniform standard for the format of 
electronic patient records. This can be the DICOM standard or 
GEHR format, for example. The standard format is used 
particularly for efficient and widespread editability and 
accessibility of the data. It is firmly prescribed by the 
manufacturer according to the legal licensing. No attention is 
given in this context to simple displayability and, by way of 
example, the national language of the user. In this respect, 
the syntax of the data format is normally a basal programming 
language with a low level of development, e.g. XML. 
Accordingly, it is assumed that a user of the first data 
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processing device 1 is trained to use this programming 
language, but may not need to have any expert medical 
knowledge . 

The first data processing device 1 has access to an interface 
11 via which it can transfer or receive data from data objects 
or complete data objects. The interface 11 comprises a data 
link together with a suitable communication protocol which 
permits the data to be transmitted . between the first data 
processing device 1 and the other, second data processing 
devices 13, 13', 13". The interface 11 can operate on an 
Internet or Intranet basis, with telephone or mobile telephone 
radio support. It is also possible for the interface to be a 
logical interface within a computer. The second data processing 
devices 13, 13 1 , 13" each have a keyboard 15, 15 1 , 15" and a 
screen 17, 17 1 , 17" for presenting and editing the data 
objects. These can be portable or permanently installed 
computers or medical workstations or other data processing 
devices. To receive the data or data objects, they access an 
interface 12 which can be connected to the interface 11. For 
this purpose, the interfaces 11, 12 are able to use the same 
communication protocol. 

The second data processing devices 13, 13 1 , 13" are used for 
presenting data from data objects for users who are medically 
trained, but may be untrained in the use of less highly 
developed programming languages such as those used for 
programming the data objects for the patient record. 
Presentation of the data by the second data processing devices 
13, 13 ' , 13" is optimized in terms of the legibility and 
clarity of the data. It is not firmly prescribed- by the 
manufacturer by rather can be prescribed or altered by. users 
themselves who are not experienced in programming language and 
data syntax. In addition, it should also be able to be 
configured differently according to the data contained in the 
presentation, e.g. certain configurations should be used for 
certain diagnosis types or for certain urgency types. Since, in 
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addition, the data objects are accessed from different 
locations by different users and with different aims, 
respective different forms of display should also be available 
for this purpose. To this end, the second data processing 
devices 13, 13 ' , 13" each have dedicated mask memories 19, 19', 
19" which contain report masks matched to the respective 
application for the purpose of displaying the. data. In 
addition, generic report masks are available therein which 
allow clear presentation of patient data for which it has not 
been possible to find a suitable specific report mask. The 
generic report masks prescribed can then be displays of the 
data in tree structures or tables, for example. 

The report masks are designed such that they display only the 
respective relevant data from the patient record in a form 
suitable for the respective diagnosis or for the respective 
user. Should all data be relevant for a presentation, all the 
data of a data object can also be displayed. Depending on the 
structure of the patient record, it can furthermore also be 
appropriate to display data from a plurality of data objects 
together. The form of display is intended to be able to be 
altered by the respective user, for example in order to be able 
to influence formal changes to the letterhead or aspects of the 
content of the display. The mask memories 19, 19 ■ , 19" 
therefore each contain dedicated report masks which can be 
created on the basis of a suitable report language and need 
only observe the data format of the data object interface 11. 
Since the report, syntax should also be familiar to untrained 
users where possible, reports in Microsoft Word format are 
suitable for this, for example. 

To be able to present data from the patient record which have 
been received via the interface 12, the reports incorporate 
data fields using a data application suitable for this purpose 
which also provides the unprofessional user with easy- to-handle 
design and editing options, e.g. Microsoft Visual Basic for 
Applications. This data application is able to display and also 
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to alter the data. This makes it possible to provide the user 
with the option of not only presenting but also altering the 
data for the patient record, e.g. adding to or aligning 
findings. A storage thereof in the patient record, that is to 
say following transfer by the interfaces 11, 12 to the 
associated data objects in the. data store 9, can be prompted 
after any change or whenever a work session has been closed, 
for example. 

The concept of locally alterable report masks makes it possible 
to support any number of report masks and to add new report 
masks for needs which arise in the future. At the same time, 
the format of the actual database, the electronic patient 
record, remains undisturbed, and the database therefore 
continues at all times to be based on the specifications which 
governed its admission at that time. In other words, changes to 
the report masks do not result in its losing its license which 
is required for operating a technical medical appliance. 

The system described comprises two components which are both 
able to process data autonomously. The two components can run 
on the same or separate computers. The only absolute necessity 
is interconnected interfaces 11, 12 which the two components 
can use to interchange data for the patient record. 

The first component, the first data processing device 1, in 
this arrangement is an application which, by way of example, 
produces a medical workstation, i.e. it can display, receive, 
edit and send diagnostic data. In this context, it uses a 
recognized protocol, such as DICOM or GEHR, which supports the 
transfer and storage of metadata and image data. In addition, 
the first data processing device 1 ensures the observance of 
data security rules which cannot be influenced by the user. By 
way of example, by authenticating all data access operations, 
it ensures that not every user can read or modify all data, but 
rather only a user who is entitled to do so. In addition, it 
also ensures documentation of all data access operations in 
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order to permit later reconstruction of read or write access 
operations by any users to any data objects. Similarly to the 
dependence on the data formats of the patient records, the 
technical medical [lacuna] is also dependent on the security 
components and on the fact that these cannot be altered by the 
user. He can neither change or deactivate the security requests 
for authentication nor can he influence or alter the contents 
of the documentation. Hence, the inaccessible implementation of 
the security components in the first data processing device 1 
also helps to maintain the technical medical license for as 
long a term as possible. 

The second component, the second data processing device 13, 
13 1 , 13", preferably supports a word processing application. 
This application is able to use a macrolanguage for the purpose 
of autonomously executing a program which can access the data 
in the data objects from the patient record. Instead of a word 
processing application, however, it is also possible to use a 
spreadsheet application, for example, in order to start 
arithmetic analysis of the patient data. The spreadsheet can 
ascertain statistical data, e.g. can generate the frequency of 
stages of illness, graphical displays of trends during the 
course of the illness, e.g. the evolution of the body 
temperature or frequency of attacks of tachycardia, or can 
create statistical graphs from the data from patient 
collectives. It is also possible to use all other data 
processing programs for office use, "office programs", for the 
data processing. 

When the user starts the second component, a particular report 
mask is loaded from a report mask memory 19, 19', 19" which 
contains initially empty data fields instead of data from the 
patient record. To enter values into the empty data fields, the 
macrolanguage of the office program accesses the interface 12 
and fetches the necessary patient data therefrom. In the 
process, it also transfers the user data which are required for 
authentication and documentation. The patient data are added to 
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the respective office program to generate, store, print, send 
etc. reports and graphs. 

If the user makes changes to the data which are present in the 
data record, that is to say to the values of the data in the 
data fields, these altered data can be transmitted back via the 
interfaces 11, 12. In addition, the user data for 
authentication and documentation are transmitted at the same 
time as the data are transmitted back, if appropriate. The 
interfaces 11, 12 thus operate bidirectionally . Data 
transmitted back are checked for plausibility before they are 
written to the data store 9 by the first data processing device 
1 . By way of example, it is possible to check whether the 
indication of a patient's weight comes within natural limits, - 
whether findings which have been input conflict with the 
patient record available to date or whether sex-specific 
findings, such as pregnancy, have actually been indicated only 
for patients of the correct sex. 

Figure 2 shows a system in accordance with the invention in 
which the operation of the interface 11 has been complemented 
by a data switching device 21. Otherwise, the system shown in 
Figure 2, together with all the references, is equivalent to 
that shown in Figure 1. The data switching device 21 adds to 
the system a communication component which is registered on the 
first data processing device 1 as an available application. 
This application is available to the second data processing 
devices 13, 13 1 , 13", or to the applications running thereon, 
for data access. It mediates between the applications and the 
data store 9 for the first data processing device 1 and the 
applications for the second data processing devices 13, 13', 
13". 

If the applications for the second data processing devices 13, 
13', 13" are Microsoft -based applications, then the data 
switching device 21 is entered as an object in the "Running 


200211733 - 12 - 

Object Table" (ROT) . Microsoft applications can access the ROT 
and can ascertain whether the data switching device 21 is 
available. They can then access the functions of the data 
switching device 21 in order to request data objects for the 
patient record from the data store 9 or to store them in the 
data store 9. 

The data switching device 21 accesses an association database 
23 storing information about the association between particular 
types of patient data and report masks. The data switching 
device 21 first checks the type of the requested data obj ect 
from the patient record, e.g. whether the data object contains 
diagnostically or therapeutically oriented patient data or on 
which diagnosis it is -based, uses the information in the 
association database 23 to ascertain the name of the associated 
report mask, and transmits this name to the interface 11. Next, 
the data switching device 21 transmits the requested metadata 
or image data and makes them available to the requesting data 
processing device. 

If appropriate, the selection of the name of the report mask 
can additionally be supported interactively by virtue of the 
user being asked via the connected interfaces 11, 12, by way of 
example, which office application or which report form the 
second data processing device 13, 13 1 , 13" needs to use to 
process the data. In addition, other information from the first 
data processing device 1 or from the second data processing 
device 13, 13 1 , 13" can go into the selection of the report 
mask . 

If data need to be stored back to the patient record in the 
data store 9, the data switching device 21 undertakes checking 
of the data which are to be written back for their plausibility 
or consistency with the rest of the patient record. In 
addition, the data switching device 21 prompts storage of all 
access operations and operations for documentation purposes. 
These can also include access operations to the patient record 
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which are not connected to the alteration of patient data. The 
documentation of the access operations and the other operations 
serves firstly for legally required documentation and can 
secondly assist a billing system. 

Figure 3 shows the distributed method in accordance with the 
invention. The first method component 30 involves the data 
objects being generated or being received from a modality in 
method step 31. In step 33, the data objects can be viewed and 
edited, with no variable formats being available for viewing 
and editing. Instead, the application is tied to firmly 
prescribed formats which are defined within the framework of 
legally required licensing of the method. In step 35, the data 
objects are formatted in line with the licensing specifications 
for storage, and the formatted data objects are stored in step 
37. The format of the data is part of the legal licensing and 
is firmly prescribed, by the manufacturer. It cannot be 
influenced by the user. 

Storage can take place only if the memory access can be 
authenticated by the user in step 39. Without successful 
authentication, the user cannot perform any write access and 
possibly any read access either to the data object memory. 
Storage of the data is also documented in connection with the 
authentication in step 39, which means that it is always 
possible to reconstruct at later times which user has accessed 
the data at what time and in what way. Authentication and 
documentation, like the prescription of data formats, are thus 
performed on the basis of the legal specifications and cannot 
be influenced by the user in any way, since any changes to 
these method steps could result in the loss of the licensing. 

The data switching component 4 0 can send the data from the data 
objects to the second method component 44, so that they can be 
presented there in more readable and manageable data formats. 
Data access by the data switching component 4 0 is documented 
and authenticated, like any data access, in step 39, which is 
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why information about the respective accessing user also needs 
to be interchanged. The data can be sent on request, according 
to particular distribution- list rules or when particular events 
occur. By way of example, a hospital can have the stipulation 
that new data from particular diagnostic examinations are 
automatically sent to the treating physician or that data are 
automatically transmitted to duty staff at emergency stations 
if data contents which are critical for the patient are 
detected . 

Within the data switching component 40, the data are taken from 
the patient record in step 41 and are sent in a format which 
can be read by the report application provided - for 
presentation. In addition, the type of data to be transmitted 
is checked in step 43 and a particular report mask suitable for 
displaying the data which are to be transmitted is allocated on 
the basis of the type of data. If it is not possible to 
ascertain a specific report mask, generic report masks are also 
available which have the clearest structure possible for 
displaying any data, e.g. a table structure or a tree 
structure. In addition, in step 43, the data content can also 
be checked to determine whether it points to a critical or 
otherwise special patient condition which necessitates 
automatic sending of the data to particular addressees, i.e. to 
emergency stations or to medical specialists in particular 
fields of expertise. 

The data are transmitted to the second method component 44. 
Within this component, the report application used to present 
the data is started in step 45. In this case, the presentation 
does not need to adhere to any legal specifications, and it is 
thus also not prescribed by the manufacturer, but rather can be 
prescribed or altered by the user. The report application is an 
application which is as widely used as possible and with which 
as many users as possible are familiar, e.g. Microsoft Word. 
The report application first opens the report mask communicated 
by the data switching component 40. If no report mask has been 
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communicated or if the report mask is not wanted, it is instead 
also possible " to open a report mask which the user requires or 
which is set as standard. In addition, the data switching 
component 44 can transmit to the user, instead of a particular 
report mask, enquiries relating thereto in order to ascertain 
the report mask which is to be opened interactively. 

In step 49, the user decides whether he wishes to use or alter 
the opened report mask or whether he wishes to create a new 
report mask. If he wants the latter, the report mask is edited 
in step 51 and is then stored in step 53. 

In step 55, when the report mask has been edited or accepted, 
an application is started which allows data to be displayed by 
the data switching component 40 in the report mask. The 
application thus combines contents of the patient record with 
the previously chosen form of presentation • for these contents. 
In this case, the combination with the presentation is made 
using commands from the application which are incorporated in 
the report mask. The application should therefore have the most 
easily manageable syntax possible which can also easily be 
learned by the layman so that he can easily make alterations to 
the report mask in respect of the illustrated contents as well. 
The application should be familiar to the unprofessional user 
for this purpose or should run in an application environment 
with which the user is familiar. Particularly in the case of 
the report application Microsoft Word, the use of Visual Basic 
for Applications is suitable. This macrolanguage has readable 
and comprehensible commands which can also be produced using 
the user interface without any special knowledge. It therefore 
becomes accessible at least to the interested user without any 
particular difficulty, and the user is able to generate and 
alter report masks, including the data fields which are to be 
incorporated, according to his own needs. 

In step 57, the data from the patient record are presented in 
the report mask which has been opened. The user, can store, 
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print or send the presentation, e.g. a Word form or a 
spreadsheet graph . 

In step 59, the user decides whether he wishes to change or 
input the displayed data from the patient record. If he does 
not wish to do so, the method is ended in the next step 61. If 
he does, the patient data are edited in step 63. To this end, 
the user can change, add to, delete or input the contents of 
the data fields in the presentation. This is done in the report 
application's user interface with which he is familiar, and 
also in the context familiar to him in which the report mask 
presents the data. In step 65, the altered data are stored. 
This can be done either automatically at particular intervals 
of time, whenever leaving a data field or upon a command from 
the user. 

The stored data are transmitted to the data switching component 
40, possibly with user data for authentication and 
documentation. The data switching component 40 is able to 
handle data from the report application, and receives these 
data in step 67. In step 69, the data are subjected to a 
plausibility check. This involves checking, inter alia, whether 
altered data are consistent with the rest of the data for the 
record and whether the alteration can be appropriate per se . By 
way of example, it is not possible to diagnose pregnancy for a 
male patient, or a patient cannot have halved his body weight 
within a few days. Data identified as being plausible are 
transmitted to the first method component 30, where they are 
formatted in step 35 according to the storage specifications 
for data objects, are stored back in step 37, and the data 
access is documented and authenticated in step 39. 


